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Real-Time  Scheduling  Theory  and  Ada 

Abstract;  The  Ada  tasking  model  was  intended  to  support  the  management  of 
concurrency  in  a  priority-driven  scheduling  environment.  In  this  paper,  we  review 
some  important  results  of  a  priority-based  scheduling  theory,  illustrate  its  applica¬ 
tions  with  examples,  discuss  its  implications  for  the  Ada  tasking  model,  and  sug¬ 
gest  workarounds  that  permit  us  to  implement  analytical  scheduling  algorithms 
within  the  existing  framework  of  Ada.  This  paper  is  a  revision  of  CMU/SEI-88- 
TR-33.^  A  shortened  version  is  also  being  presented  at  the  1989  Ada-Europe 
Conference. 


1.  Introduction 
1.1.  Background 

The  Real-Time  Scheduling  in  Ada  Project  at  the  Software  Engineering  Institute  is  a  coopera¬ 
tive  effort  between  the  SEI,  Carnegie  Mellon  University,  system  developers  in  industry,  Ada 
vendors,  and  DoD  agendes.  It  aims  at  applying  the  scheduling  theory  reviewed  in  this  paper 
to  the  design  and  implementation  of  hard  real-time  systems  in  Ada.  The  scheduling  algo¬ 
rithms  and  theories  developed  under  this  project  and  at  Carnegie  Mellon  provide  an  analyt¬ 
ical  basis  for  understanding  the  timing  behavior  of  real-time  systems.  The  project  is  im¬ 
plementing  these  scheduling  algorithms  in  an  Ada  runtime  system,  and  is  coding  exampies 
of  real-time  systems  to  evaluate  the  suitability  of  the  whole  approach  using  a  generic 
avionics  application,  a  generic  missile  application,  and  a  generic  inertial  navigation  system. 
This  paper  summarizes  some  of  the  scheduling  approaches  being  studied  and  shows  how 
they  can  be  applied  in  an  Ada  context. 

Traditionally,  many  real-time  systems  use  cyclical  executives  to  schedule  concurrent 
threads  of  execution.  Under  this  approach,  a  programmer  lays  out  an  execution  timeline  by 
hand  to  serialize  the  execution  of  critical  sections  and  to  meet  task  deadlines.  While  such  an 
approach  is  adequate  for  simple  systems,  it  quickiy  becomes  unmanageable  for  large  sys¬ 
tems.  It  is  a  painful  process  to  develop  application  code  so  that  the  compiled  segments  fit 
into  the  time  slots  of  a  cyclical  executive  and  to  ensure  that  the  critical  sections  of  different 
tasks  do  not  interleave.  Forcing  programmers  to  schedule  tasks  by  fitting  code  segments  on 
a  timeline  is  no  better  than  the  outdated  approach  of  managing  memory  by  manual  memory 
overlay.  Such  an  approach  often  destroys  program  structure  and  results  in  real-time  pro¬ 
grams  that  are  difficult  to  understand  and  maintain. 

The  Ada  tasking  model  represents  a  fundamental  departure  from  the  cyclical  executive 
model.  Indeed,  the  dynamic  preemption  of  tasks  at  runtime  generates  nondeterministic 


^The  most  important  revisions  affect  our  discussion  of  aperiodic  tasks  and  our  analysis  of  how  to  support  the 
priority  ceiling  protocol. 
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timelines  that  are  at  odds  with  the  very  idea  of  a  fixed  execution  timeline.  This  nondeter¬ 
minism  seems  to  make  it  impossible  to  decide  whether  real-time  deadlines  will  be  met. 
However,  Ada’s  tasking  concepts  are  well-suited  to  the  analytic  scheduling  theories  being 
considered  in  our  project.  In  essence,  these  theories  ensure  that  as  long  as  the  CPU  utili¬ 
zation  of  all  tasks  lies  below  a  certain  bound  and  appropriate  scheduling  algorithms  are 
used  for  the  CPU  and  I/O  processing,  all  tasks  will  meet  their  deadlines  without  knowing 
exactly  when  any  given  task  will  be  running.  Even  if  there  is  a  transient  overload,  a  fixed 
subset  of  critical  tasks  will  still  meet  their  deadlines  as  long  as  their  CPU  utilizations  lie 
within  the  appropriate  bound.  The  theories  also  deal  with  aperiodic  processing  require¬ 
ments,  mode  changes,  and  jitter  requirements.  Applying  these  theories  to  Ada  makes  Ada 
tasking  truly  useful  for  real-time  applications  while  also  putting  the  development  and  mainte¬ 
nance  of  real-time  systems  on  an  analytic,  engineering  basis,  making  these  systems  easier 
to  develop  and  maintain. 


1.2.  Controlling  Priority  Inversion 

To  put  real-time  scheduling  on  an  analytical  basis,  systems  must  be  built  in  a  way  that  en¬ 
sures  ttiat  high-priority  tasks  are  minimally  delayed  by  lower  priority  tasks  when  both  are 
contending  for  the  same  resources.  Priority  inversion  occurs  when  the  use  of  a  resource  by 
a  low  priority  task  delays  the  execution  of  a  high  priority  task.  Priority  inversion  occurs  either 
when  task  priorities  are  incorrectly  assigned  or  when  they  are  not  used  correctly  when  al¬ 
locating  resources.  One  common  mistake  in  priority  scheduling  is  assigning  priorities  solely 
according  to  task  importance. 

Example  1:  Suppose  that  and  X2  are  periodic  tasks  with  periods  100  and  10,  re¬ 
spectively.  Both  of  them  are  initiated  at  t  =  0,  and  task  is  more  important  than  task 
X2.  Assume  that  task  z^  requires  1 0  units  of  execution  time  and  its  first  deadline  is  at 
t  =  100,  while  task  X2  needs  1  unit  of  execution  time  with  its  first  deadline  at  t  =  10.  If 
task  z^  is  assigned  higher  scheduling  priority  because  of  its  importance,  task  X2  will 
miss  its  deadline  unnecessarily  even  though  the  total  processor  utilization  is  only  0.2. 
Both  tasks  can  meet  their  deadlines  using  the  rate  monotonic  algorithm  [Liu  & 
Layland  73],  which  assigns  higher  priorities  to  tasks  with  shorter  periods.  In  fact, 
many  more  new  tasks  can  be  added  into  the  system  by  using  the  simple  rate 
monotonic  scheduling  algorithm. 

Although  priority  inversion  is  undesirable,  it  cannot  be  completely  eliminated.  For  example, 
when  a  low  priority  task  is  in  a  critical  region,  the  higher  priority  task  that  needs  the  shared 
data  must  wait.  Nonetheless,  the  duration  of  priority  inversion  must  be  tightly  bounded  in 
order  to  ensure  a  high  degree  of  responsiveness  and  schedulability.  Controlling  priority  in¬ 
version  is  a  system  level  problem.  The  tasking  model,  runtime  support,  program  design, 
and  hardware  architecture  should  all  be  part  of  the  solution,  not  part  of  the  problem.  For 
example,  there  is  a  serious  priority  inversion  problem  in  some  existing  IEEE  802.5  token  ring 
implementations.  While  there  are  8  priority  levels  in  the  token  arbitration,  the  queueing  of 
message  packets  is  FIFO,  i.e.,  message  priorities  are  ignored.  As  a  result,  when  a  high 
priority  packet  is  behind  a  low  priority  packet,  the  high  priority  packet  has  to  wait  not  only  for 
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the  lower  priority  packet  to  be  transmitted,  but  also  for  the  transmission  of  all  medium  priority 
packets  in  the  network.  The  result  is  "hurry-up  at  the  processor  but  miss  the  deadline  at  the 
communication  network."  Using  FIFO  queueing  in  a  real-time  system  is  a  classical  case  of 
priority  inversion  and  can  lead  to  extremely  poor  schedulability.  Priority  assignments  must 
be  observed  at  every  level  of  a  system  for  all  forms  of  resource  allocation.  Minimizing  the 
duration  of  priority  inversion  is  the  key  to  meeting  deadlines  and  keeping  systems  respon¬ 
sive  to  aperiodic  events. 

Chapter  2  reviews  some  of  the  important  results  in  real-time  scheduling  theory.  We  begin 
with  the  problem  of  scheduling  independent  periodic  tasks.  Next,  we  address  the  issues  of 
maintaining  stability  under  transient  overload  and  the  problem  of  scheduling  both  periodic 
and  aperiodic  tasks.  We  conclude  Chapter  2  by  reviewing  the  problems  of  real-time 
synchronization.  In  Chapter  3,  we  review  the  Ada  tasking  scheduling  model  and  suggest 
some  workarounds  that  permit  us  to  implement  many  of  the  scheduling  algorithms  within  the 
framework  of  existing  Ada  rules.  Finally,  we  conclude  this  paper  in  Chapter  4. 
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2.  Scheduling  Real-Time  Tasks 

In  this  chapter,  we  provide  an  overview  of  some  of  the  important  issues  of  a  real-time 
scheduling  theory.  We  will  begin  with  the  problem  of  ensuring  that  independent  periodic 
tasks  meet  their  deadlines.  Next,  we  show  how  to  ensure  that  critical  tasks  meet  their  dead¬ 
lines  even  when  a  system  is  temporarily  overloaded.  We  then  address  the  problem  of 
scheduling  both  periodic  and  aperiodic  tasks.  Finally,  we  conclude  this  chapter  by  reviewing 
the  problems  of  real-time  synchronization  and  communication. 


2.1.  Periodic  Tasks 

Tasks  are  independents  their  executions  need  not  be  synchronized.  Given  a  set  of  inde¬ 
pendent  periodic  tasks,  the  rate  monotonic  scheduiing  aigoiithm  gives  each  task  a  fixed  pri¬ 
ority  and  assigns  higher  priorities  to  tasks  with  shorter  periods.  A  task  set  is  said  to  be 
scheduiable  if  all  its  deadlines  are  met,  i.e..  If  every  periodic  task  finishes  its  execution  be¬ 
fore  the  end  of  its  period.  Any  set  of  independent  periodic  tasks  is  scheduiable  by  the  rate 
monotonic  algorithm  if  the  condition  of  Theorem  1  is  met  [Liu  &  Layland  73]. 

Theorem  1:  A  set  of  n  independent  periodic  tasks  scheduled  by  the  rate 
monotonic  algorithm  will  always  meet  its  deadlines,  for  all  task  phasings,  if 

...  +^<ni2y'^-l)  =  U(n) 

where  C,-  and  7,-  are  the  execution  time  and  period  of  task  Xj  respectively. 

Theorem  1  offers  a  sufficient  (worst-case)  condition  that  characterizes  the  schedulability  of 
the  rate  monotonic  algorithm.  This  bound  converges  to  69%  {In  2)  as  the  number  of  tasks 
approaches  infinity.  Table  2-1  shows  values  of  the  bound  for  one  to  nine  tasks. 


U(1 )  =  1 .0  U(4)  =  0.756  U(7)  =  0.728 

U(2)  =  0.828  U(5)  =  0.743  U(8)  =  0.724 

U(3)  =  0.779  U(6)  =  0.734  U(9)  =  0.720 

Table  2-1 :  Scheduling  Bounds  for  One  to  Nine  Independent  Tasks 


The  bound  of  Theorem  1  is  very  pessimistic  because  the  worst-case  task  set  is  contrived 
and  unlikely  to  be  encountered  in  practice.  For  a  randomly  chosen  task  set,  the  likely  bound 
is  88%  [Lehoczky  et  al.  87].  To  know  if  a  set  of  given  tasks  with  utilization  greater  than  the 
bound  of  Theorem  1  can  meet  its  deadlines,  the  conditions  of  Theorem  2  must  be 
checked  [Lehoczky  et  al.  87]. 

Theorem  2:  A  set  of  n  independent  periodic  tasks  scheduled  by  the  rate 
monotonic  algorithm  will  always  meet  its  deadlines,  for  all  task  phasings,  if  and 
only  if 
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V  z,  1  ^  z  ^  zz, 


mn 


IT, 


Tj 


<1 


;=i  ■  ‘  ^ 

{k,  1)  e 

where  Cj  and  Tj  are  the  execution  time  and  period  of  task  Xj  respectively  and 

=  •  ■XT/Tkl]. 


This  theorem  provides  the  exact  schedulability  criterion  for  independent  periodic  task  sets 
under  the  rate  monotonic  algorithm.  In  effect,  the  theorem  checks  if  each  task  can  complete 
its  execution  before  its  first  deadline  by  checking  all  the  scheduling  points.^  The  scheduling 
points  for  task  x  are  x’s  first  deadline  and  the  ends  of  periods  of  higher  priority  tasks  within 
x’s  first  deadline.  In  the  formula,  z  denotes  the  task  to  be  checked  and  k  denotes  each  of  the 
tasks  that  affects  the  completion  time  of  task  z,  i.e.,  task  z  and  the  higher  priority  tasks.  For  a 
given  z  and  k,  each  value  of  /  represents  the  scheduling  points  of  task  k.  For  example,  sup¬ 
pose  that  we  have  tasks  x^  and  X2  with  periods  =  5  and  72  =  14.  For  task  x^  (z  =  1)  we 
have  only  one  scheduling  point,  the  end  of  task  x^’s  first  period,  i.e.,  z=il:=l  and 
(/=  1,  •  •  •  ,  L7/7jJ  =  L7i/7i J  =  1).  The  scheduling  point  is,  of  course,  x^’s  first  deadline 
(/  7^  =  5,  /  =  1,  /:  =  1).  For  task  Xg  (i  =  2),  there  are  two  scheduling  points  from  all  higher 
priority  tasks,  X;^  {k=  1),  i.e.,  (/=  1,  •  •  • ,  [7/7^^]  =  L72/7j J  =  2).  The  two  scheduling  points 
are,  of  course,  the  two  end  points  of  task  x^’s  period  within  the  first  deadline  of  task  X2  at  14, 
i.e.,  (/  7^  =  5,  /  =  1,  /:  =  1)  and  (/  Tf,  =  10, 1  =  2,  k=  1).  Finally,  there  is  the  scheduling  point 
from  X2’s  own  first  deadline,  i.e.,  (/  7^  =  14,  /  =  l,k  =  2).  At  each  scheduling  point,  we  check 
if  the  task  in  question  can  complete  its  execution  at  or  before  the  scheduling  point.  This  is 
illustrated  in  detail  by  Examples  3  and  8  below. 

Example  2:  Consider  the  case  of  three  periodic  tasks,  where  U^  =  C/T^. 

•  Task x^:  q  =  20  :  7i  =  100  :  =  0.2 

•  Task  X2;  C2  =  40  :  72  =  150  ;  1/2  =  0.267 

•  T ask  X3;  C3  =  1 00  :  73  =  350  ;  L/3  =  0.286 

The  totai  utilization  of  these  three  tasks  is  0.753,  which  is  below  Theorem  1’s  bound 
for  three  tasks:  3(2^^  -  1)  =  0.779.  Hence,  we  know  these  three  tasks  are  schedul- 
able,  i.e.,  they  will  meet  their  deadlines  if  x.,  is  given  the  highest  priority,  X2  the  next 
highest,  and  X3  the  lowest. 

The  remaining  24.7%  progessor  capacity  can  be  used  for  low  priority  background 
processing.  However,  we  can  also  use  it  for  additional  hard  real-time  computation. 


Example  3:  Suppose  we  replace  x^’s  algorithm  with  one  that  is  more  accurate  and 
computationally  intensive.  Suppose  the  new  algorithm  doubles  x^’s  computation 
time  from  20  to  40,  so  the  total  processor  utilization  increases  from  0.753  to  0.953. 
Since  the  utilization  of  the  first  two  tasks  is  0.667,  which  is  below  Theorem  1  ’s  bound 


^It  was  shown  in  [Uu  &  Layland  73]  that  when  all  the  tasks  are  initiated  at  the  same  time  (the  worst-case 
phasing),  if  a  task  completes  its  execution  before  the  end  of  its  first  period,  it  will  never  miss  a  deadline. 
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for  two  tasks,  2(2^^  -  1)  =  0.828,  the  first  two  tasks  cannot  miss  their  deadlines.  For 
task  Tg,  we  use  Theorem  2  to  check  whether  the  task  set  is  schedulable,  i.e.,  we  set  i 
=  n  =  3,  and  check  whether  one  of  the  following  equations  holds: 


Vit,/, 


IT, 


Tj 


Cj  <  IT^ 


To  check  If  task  Xg  can  meet  Its  deadline,  it  is  only  necessary  to  check  the  equation 
for  values  of  /  and  k  such  that  350.  If  one  of  the  equations  Is  satisfied,  the 

task  set  is  schedulable. 


C<^  +  C2 

T, 

or 

2Ci 

+  Cg 

VI 

or 

2Ci 

+  2C2 

+  P3  ^  2T, 

or 

3Ci 

+  2C2 

+  Cj  £  272 

or 

4Ci 

+  3O2 

+  <  7g 

40  +  40  + 100  >  100 
80 +  40 +  100  >150 
80 +  80 +  100  >200 
120  +  80  +  100  =  300 
160 +  120 +  100  >350 


/=1,it=1 
l=^.k  =  2 
1  =  2,  k=^ 

/  =  2,  it  =  2,  or/  =  3,  it  =  l3 
/=1,it  =  3 


The  analysis  shows  that  task  Xg  is  also  schedulable  and  in  the  worst-case  phasing 
will  meet  its  deadline  exactly  at  time  300.  Hence,  we  can  double  the  utilization  of  the 
first  task  from  20%  to  40°/o  and  still  meet  all  the  deadlines.  The  remaining  4.7% 
processor  capacity  can  be  used  for  either  background  processing  or  a  fourth  hard 
deadline  task,  which  has  a  period  longer  than  that  of  Xg^  and  which  satisfies  the  con¬ 
dition  of  Theorem  2. 


A  major  advantage  of  using  the  rate  monotonic  algorithm  is  that  it  allows  us  to  separate 
logical  correctness  concerns  from  timing  correctness  concerns.  Suppose  that  a  cyclical  ex¬ 
ecutive  is  used  for  this  example.  The  major  cycle  must  be  the  least  common  multiple  of  the 
task  periods.  In  this  example,  the  task  periods  are  in  the  ratio  100:150:350  =  2:3:7.  A  minor 
cycle  of  50  units  would  induce  a  major  cycle  of  42  minor  cycles,  which  is  an  overly  complex 
design.  To  reduce  the  number  of  minor  cycles,  we  can  try  to  modify  the  periods.  For  ex¬ 
ample,  it  might  be  possible  to  reduce  the  period  of  the  longest  task,  from  350  to  300.  The 
total  utilization  is  then  exactly  100%,  and  the  period  ratios  are  2:3:6;  the  major  cycle  can 
then  be  6  minor  cycles  of  50  units.  To  implement  this  approach  and  minimize  the  splitting  of 
computations  belonging  to  a  single  task,  we  could  split  task  x.,  into  two  parts  of  20  units 
computation  each.  The  computation  of  task  Xg  similarly  could  be  split  into  at  least  two  parts 
such  that  task  Xg  need  only  be  split  into  four  parts.  A  possible  timeline  indicating  the  amount 


^That  is,  after  300  units  of  time,  will  have  run  three  times,  Xj  will  have  run  twice,  and  X3  will  have  run  once. 
The  required  amount  of  computation  just  fits  within  the  allowed  time,  so  each  task  meets  its  deadline.  [Liu  & 
Layland  73]  showed  that  since  the  tasks  meet  their  deadlines  at  least  once  within  the  period  Ty  they  will  always 
meet  their  deadlines. 

^Task  X3  just  meets  its  deadline  at  300  and  hence  we  cannot  add  a  task  with  a  priority  higher  than  that  of  task 
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of  computation  for  each  task  in  each  minor  cycle  is  shown  in  the  following  table,  where  20^ 
on  the  first  line  indicates  the  first  part  of  task  x^’s  computation,  which  takes  20  units  of  time. 


Cyclic  Timeline  for  Example  3 

1 

2 

3 

4 

5 

6 

^1 

2O1 

CM 

0 

CNJ 

2O1 

2O2 

2O1 

2O2 

^2 

30i 

IO2 

30i 

IO2 

2O1 

3O2 

2O3 

0 

CO 

Table  2-2:  Minor  Cycle  nmeline:  Each  Minor  Cycle  Is  50. 

When  processor  utilization  level  is  high  and  there  are  many  tasks,  fitting  code  segments  into 
time  slots  can  be  a  time-consuming  iterative  process.  In  addition,  a  later  modification  of  any 
task  may  overflow  a  particular  minor  cycle  and  require  the  entire  timeline  to  be  redone.  But 
more  important,  the  cyclic  executive  approach  has  required  us  to  modify  the  period  of  one  of 
the  tasks,  increasing  the  utilization  to  100%  without  in  fact  doing  more  usefui  work.  Under 
the  rate  monotonic  approach  for  this  example,  all  deadlines  are  met,  but  total  machine  utili¬ 
zation  must  be  95.3%  or  less  instead  of  100%  or  less.  This  doesn’t  mean  the  rate 
monotonic  approach  is  less  efficient.  The  capacity  that  isn’t  needed  to  service  real-time 
tasks  in  the  rate  monotonic  approach  can  be  used  by  background  tasks,  e.g.,  for  built-in-test 
purposes.  With  the  cyclic  executive  approach,  no  such  additional  work  can  be  done  in  this 
example.  Of  course,  the  scheduling  overhead  for  task  preemption  needs  to  be  taken  into 
account.  If  S  is  the  amount  of  time  needed  for  a  single  scheduling  action,  then  the  total 
utilization  devoted  to  scheduling  is  2S/Ti  -i-  2S/T2  -1-  2S/T3  since  there  are  two  scheduling 
actions  per  task.  In  the  cyclic  case,  the,  scheduling  overhead  is  partly  in  the  (very  small) 
time  needed  to  dispatch  each  task’s  code  segment  in  each  minor  cycle  and  partly  in  the 
utilization  wasted  by  decreasing  the  period  for  task  3.  For  this  example,  the  scheduling 
overhead  for  the  cyclic  approach  is  at  least  4.7%: 

Actuai_Utiiization  -  Required_Utiiization,  i.e., 

100/300  -  100/350  =  .333  -  .286  =  .047 

Thus,  although  the  rate  monotonic  approach  may  seem  to  yield  a  lower  maximum  utilization 
than  the  cyclic  approach,  in  practice,  the  cyclic  approach  may  simply  be  consuming  more 
machine  time  because  the  periods  have  been  artificially  shortened.  In  addition,  cyclic  ex¬ 
ecutives  get  complicated  when  they  have  to  deal  with  aperiodic  events.  The  rate  monotonic 
approach,  as  will  be  discussed  later,  readily  accommodates  aperiodic  processing.  Finally, 
the  rate  monotonic  utilization  bound  as  computed  by  Theorem  2  is  a  function  of  the  periods 
and  computation  times  of  the  task  set.  The  utilization  bound  can  always  be  Increased  by 
transforming  task  periods,  as  described  In  the  next  section. 
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2.2.  Stability  Under  Transient  Overload 

In  the  previous  section,  the  computation  time  of  a  task  is  assumed  to  be  constant.  However, 
in  many  applications,  task  execution  times  are  stochastic,  and  the  worst-case  execution  time 
can  be  significantly  larger  than  the  average  execution  time.  To  have  a  reasonably  high 
average  processor  utilization,  we  must  deal  with  the  problem  of  transient  overload.  During 
transient  overload,  we  want  to  guarantee  the  deadlines  of  the  tasks  that  are  critical  to  the 
mission,  even  at  the  cost  of  missing  the  deadlines  of  non-crit'cal  tasks. 

We  consider  a  scheduling  algorithm  to  be  stable  if  there  is  a  fixed  set  of  tasks  (the  stable 
set)  that  always  meet  their  deadlines  even  if  the  processor  is  overloaded.  Tasks  outside  the 
stable  set  may  miss  their  deadlines  as  the  processor  load  increases  or  as  task  phasings 
change.  To  ensure  that  the  critical  tasks  always  meet  their  deadlines,  it  is  sufficient  for  them 
to  belong  to  the  stable  set  of  tasks. 

The  rate  monotonic  algorithm  is  a  stable  scheduling  algorithm.  Suppose  there  are  n  tasks. 
The  stable  set  consists  of  the  first  k  highest  priority  tasks  that  satisfy  Theorem  1  or  2.  For 
example,  if  the  utilization  of  the  first  k  tasks  is  less  than  69.3%,  the  tasks  will  always  meet 
their  deadlines  no  matter  what  the  total  processor  load  is.  Of  course,  which  tasks  are  in  the 
stable  task  set  depends  on  the  worst-case  utilizations  of  the  particular  tasks  considered. 
The  important  point  is  that  the  rate  monotonic  algorithm  guarantees  that  if  such  a  set  exists, 
it  always  consists  of  tasks  with  the  highest  priorities.  This  means  that  if  a  transient  overload 
should  develop,  tasks  with  longer  periods  will  miss  their  deadlines. 

Of  course,  a  task  with  a  longer  period  could  be  more  critical  to  an  application  than  a  task 
with  a  shorter  period.  One  might  attempt  to  ensure  that  the  critical  task  always  meets  its 
deadline  by  assigning  priorities  according  to  a  task’s  importance.  However,  this  approach 
can  lead  to  poor  schedulability.  That  is,  with  this  approach,  deadlines  of  critical  tasks  might 
be  met  only  when  the  total  utilization  is  low. 

The  period  transformation  technique  can  be  used  to  ensure  high  utilization  while  meeting 
the  deadline  of  an  important,  long-period  task.  Period  transformation  means  turning  a  long- 
period  important  task  Into  a  high  priority  task  by  splitting  its  work  over  several  short  periods. 
For  example,  suppose  task  x  with  a  long  period  T  is  not  in  the  critical  task  set  and  must 
never  miss  its  deadline.  We  can  make  x  simulate  a  short  period  task  by  giving  it  a  period  of 
T12  and  suspending  it  after  it  executes  half  its  worst-case  execution  time,  C/2.  The  task  is 
then  resumed  and  finishes  its  work  in  the  next  execution  period.  It  still  completes  its  total 
computation  before  the  end  of  period  T.  From  the  viewpoint  of  the  rate  monotonic  theory, 
the  transformed  task  has  the  same  utilization  but  a  shorter  period,  772,  and  its  priority  is 
raised  accordingly.  It  is  Important  to  note  that  the  most  important  task  need  not  have  the 
shortest  period.  We  only  need  to  make  sure  that  it  is  among  the  first  n  high  priority  tasks 
whose  worst-case  utilization  is  within  the  scheduling  bound.  A  systematic  procedure  for 
period  transformation  with  minimal  task  partitioning  can  be  found  in  [Sha  et  al.  86]. 

Period  transformation  allows  important  tasks  to  have  higher  priority  while  keeping  priority 
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assignments  consistent  with  rate  monotonic  rules.  This  kind  of  transformation  should  be 
familiar  to  users  of  cyclic  executives.  The  difference  here  is  that  we  don’t  need  to  adjust  the 
code  segment  sizes  so  different  code  segments  fit  into  shared  time  slots.  Instead,  t  simply 
requests  suspension  after  performing  C/2  amount  of  work.  Alternatively,  the  runtime 
scheduler  can  be  instructed  to  suspend  the  task  after  a  certain  amount  of  computation  has 
been  done,  without  affecting  the  application  code.® 


The  period  transformation  approach  has  another  benefit  —  it  can  raise  the  rate  monotonic 
utilization  bound.  Suppose  the  rate  monotonic  utilization  bound  is  Uj^  <  100%,  i.e.,  total 
task  utilization  cannot  be  increased  above  without  missing  a  deadline.  When  a  period 
transformation  is  applied  to  the  task  set,  will  rise.  For  example: 

Example  4:  Let 

•  TaskT,:  Cj  =  4  ;  Tj  =  10  ;  t/i  =  .400 

•  TaskT2:  C2  =  6  ;T'2  =  14  ;  t/2  =  .428 


The  total  utilization  is  .828,  which  just  equals  the  bound  of  Theorem  2,  so  this  set  of 
two  tasks  is  schedulable.  If  we  apply  Theorem  2,  we  find; 

C^  +  C2<T^  4  +  6  =  10  l=^,lc=^ 

or  2Ci+C2<r2  8  +  6  =  14  /  =  1,/:  =  2 

So  Theorem  2  says  the  task  set  is  just  schedulable.  Now  suppose  we  perform  a 
period  transformation  on  task  t.|,  so  C{  =  2  and  T[  =  5.  The  total  utilization  is  the 
same  and  the  set  is  still  schedulable,  but  when  we  apply  Theorem  2  we  find: 


C.|  +  C2  ^  T■^ 

2  +  6>5 

l  =  ^,k  = 

or 

2Ci  +  C2  <27, 

4  +  6  =  10 

l  =  2,k  = 

or 

3Ci  +  C2  <  T2 

6  +  6<14 

l=^.k  = 

The  third  equation  shows  that  the  compute  times  for  tasks  and/or  T2  can  be  in¬ 
creased  without  violating  the  constraint.  For  example,  the  compute  time  of  task 
can  be  increased  by  2/3  units  to  2.667,  giving  an  overall  schedulable  utilization  of 
2.667/5  +  6/14  =  .961,  or  the  compute  time  of  Task  T2  can  be  increased  to  8,  giving 
an  overall  schedulable  utilization  of  2/5  +  8/14  =  .971.  So  the  effect  of  the  period 
transformation  has  been  to  raise  the  utilization  bound  from  .828  to  at  least  .961  and 
at  most  .971. 


If  periods  are  uniformly  harmonic,  i.e.,  if  each  period  is  an  integral  multiple  of  each  shorter 


^The  scheduler  must  ensure  that  t  is  not  suspended  while  in  a  critical  regbn  since  such  a  suspensbn  can 
cause  other  tasks  to  miss  their  deadlines.  If  the  suspensbn  time  arrives  but  the  task  is  in  a  critical  regbn,  then 
the  suspensbn  shoub  be  delayed  until  the  task  exits  the  critical  regbn.  To  account  for  this  effect  on  the 
schedulability  of  the  task  set,  the  worst-case  executbn  time  must  be  increased  by  c,  the  extra  time  spent  in  the 
critical  regbn,  i.e.,  t's  utilizatbn  becomes  {0.5C+e)/0.5T. 
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period,  the  utilization  bound  of  the  rate  monotonic  algorithm  is  100%.®  So  the  utilization 
bound  produced  by  the  rate  monotonic  approach  is  only  an  upper  bound  on  what  can  be 
achieved  if  the  periods  are  not  transformed.  Of  course,  as  the  periods  get  shorter,  the 
scheduling  overhead  utilization  increases,  so  the  amount  of  useful  work  that  can  be  done 
decreases.  For  example,  before  a  period  transformation,  the  utilization  for  a  task,  including 
scheduling  overhead,  is  (C  +  25)/r.  After  splitting  the  period  into  two  parts,  the  utilization  is 
(.5C  +  2S)I.5T,  so  scheduling  overhead  is  a  larger  part  of  the  total  utilization.  However,  the 
utilization  bound  is  also  increased  in  general.  If  the  increase  in  utilization  caused  by  the 
scheduling  overhead  is  less  than  the  increase  in  the  utilization  bound,  then  the  period  trans¬ 
formation  is  a  win  —  more  useful  work  can  be  done  while  meeting  all  deadlines. 


2.3.  Scheduling  Both  Aperiodic  and  Periodic  Tasks 

It  is  important  to  meet  the  regular  deadlines  of  periodic  tasks  and  the  response  time  require¬ 
ments  of  aperiodic  events.  ("Aperiodic  tasks"  are  used  to  service  such  events.)  Let  us 
begin  with  a  simple  example. 

Example  5:  Suppose  that  we  have  two  tasks.  Let  be  a  periodic  task  with  period 
1 00  and  execution  time  99.  Let  X2  be  an  aperiodic  task  that  appears  once  within  a 
period  of  100  but  the  arrival  time  is  random.  The  execution  time  of  task  X2  is  one 
unit.  If  we  let  the  aperiodic  task  wait  for  the  periodic  task,  then  the  average  response 
time  is  about  50  units.  The  same  can  be  said  for  a  polling  server,  which  provides 
one  unit  of  service  time  in  a  period  of  100.  On  the  other  hand,  we  can  deposit  one 
unit  of  service  time  in  a  "ticket  box"  every  100  units  of  time;  when  a  new  "ticket"  is 
deposited,  the  unused  old  tickets,  if  any,  are  discarded.  With  this  approach,  no  mat¬ 
ter  when  the  aperiodic  event  arrives  during  a  period  of  100,  it  will  find  there  is  a  ticket 
for  one  unit  of  execution  time  at  the  ticket-box.  That  is,  X2  can  use  the  ticket  to 
preempt  x■^  and  execute  immediately  when  the  event  occurs.  In  this  case,  X2’s  re¬ 
sponse  time  is  precisely  one  unit  and  the  deadlines  of  x■^  are  still  guaranteed.  This  is 
the  idea  behind  the  deferrable  server  algorithm  [Lehoczky  87],  which  reduces 
aperiodic  response  time  by  a  factor  of  about  50  in  this  example. 

In  reality,  there  can  be  many  periodic  tasks  whose  periods  can  be  arbitrary.  Furthermore, 
aperiodic  arrivals  can  be  very  bursty,  as  for  a  Poisson  process.  However,  the  idea  remains 
unchanged.  We  should  allow  the  aperiodic  tasks  to  preempt  the  p>eriodic  tasks  subject  to 
not  causing  their  deadlines  to  be  missed.  It  was  shown  in  [Lehoczky  87]  that  the  deadlines 
of  periodic  tasks  can  be  guaranteed  provided  that  during  a  period  of  Tg  units  of  time,  there 
are  no  more  than  Cg  units  of  time  in  which  aperiodic  tasks  preempt  periodic  tasks.  In  addi¬ 
tion,  the  total  periodic  and  aperiodic  utilization  must  be  kept  below 
(U^  +  ln[(2  +  U^IQXJ^  -H  1))],  where  =  CJT^.  Ar»d  the  server’s  period  must  observe  the 
inequality  ^  (7  -  C^)",  where  T  is  the  period  of  a  periodic  task  whose  priority  is  next  to 
the  server. 


^For  example,  by  transforming  the  periods  in  Example  3  so  and  x^  both  have  periods  of  50,  the  utilization 
bound  is  100%,  i.e.,  4.7%  more  work  can  be  done  without  missing  a  deadline. 
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Compared  with  background  service,  the  deferrable  server  algorithm  typically  improves 
aperiodic  response  time  by  a  factor  between  2  and  10  [Lehoczky  87].  Under  the  deferrable 
server  algorithm,  both  periodic  and  aperiodic  task  modules  can  be  modified  at  will  as  long  as 
the  utilization  bound  is  observed. 

A  variation  of  the  deferrable  server  algorithm  is  known  as  the  sporadic  server 
algorithm  [Sprunt  et  al.  89].  As  for  the  deferrable  server  algorithm,  we  allocate  units  of 
computation  time  within  a  period  of  Tg  units  of  time.  However,  the  Cg  of  the  server’s  budget 
is  not  refreshed  until  the  budget  Is  consumed.^  From  a  capacity  planning  point  of  view,  a 
sporadic  server  is  equivalent  to  a  periodic  task  that  performs  polling.  That  is,  we  can  place 
sporadic  servers  at  various  priority  levels  and  use  only  Theorems  1  and  2  to  perform  a 
schedulability  analysis.  Sporadic  and  deferrable  servers  have  similar  performance  gains 
over  polling  because  any  time  an  aperiodic  task  arrives,  it  can  use  the  allocated  budget 
immediately.  When  polling  is  used,  however,  an  aperiodic  arrival  generally  needs  to  wait  for 
the  next  instant  of  polling.  The  sporadic  server  has  the  least  runtime  overhead.  Both  the 
polling  and  the  deferrable  servers  have  to  be  serviced  periodically,  even  if  there  are  no 
aperiodic  arrivals.®  There  is  no  overhead  for  the  sporadic  server  until  its  execution  budget 
has  been  consumed.  In  particular,  there  is  no  overhead  if  there  are  no  aperiodic  arrivals. 
Therefore,  the  sporadic  server  is  especially  suitable  for  handling  emergency  aperiodic 
events  that  occur  rarely  but  must  be  responded  to  quickly. 


Response  Time 
Relative  to 
Background  Service 

Periodic  Load  =  40% 


Figure  2-1 :  Scheduling  Both  Aperiodic  and  Periodic  Tasks 


^Early  refreshing  is  also  possible  under  certain  conditions.  See  [Sprunt  et  al.  89]. 
®The  ticket  box  must  be  refreshed  at  the  end  of  each  deferable  server’s  perfod. 
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Simulation  studies  of  the  sporadic  server  algorithm  [Sprunt  et  al.  89]  show  that  in  a  lightly 
loaded  system,  aperiodic  events  are  served  5-10  times  faster  than  with  background  service, 
and  3-6  times  faster  than  with  polling.  Figure  2-1,  from  [Sprunt  et  al.  89],  shows  one  ex¬ 
ample  of  the  relative  performance  between  background  execution,  the  deferrable  server  al¬ 
gorithm  (DS),  the  sporadic  server  algorithm  (SS),  polling,  and  another  algorithm,  not  ex¬ 
plained  here,  called  the  priority  exchange  algorithm  (PE).  The  analysis  underlying  these 
results  assumes  a  Poisson  arrival  process  with  exponentially  distributed  service  time.  In 
addition,  each  server  (other  than  the  background  server)  Is  given  a  period  that  allows  it  to 
execute  as  the  highest  priority  task.®  Aperiodic  requests  can  therefore  preempt  the  execu¬ 
tion  of  periodic  tasks  as  long  as  server  execution  time  is  available. 

The  maximum  amount  of  aperiodic  service  time  allowed  before  periodic  tasks  will  miss  their 
deadline  Is  called  the  maximum  server  size.  In  this  example,  aperiodic  tasks  can  preempt 
periodic  tasks  for  at  most  56.3%  of  the  sporadic  or  polling  server’s  period  without  causing 
the  deadlines  of  periodic  tasks  to  be  missed.  For  the  deferrable  server,  only  a  smaller 
amount  of  service  time  Is  possible:  43.6%.  In  either  case,  the  server  is  not  allowed  to  ex¬ 
ecute  at  its  assigned  priority  once  its  computation  budget  is  exhausted,  although  It  can  con¬ 
tinue  to  execute  at  background  priority  if  time  is  available.  A  server’s  budget  is  refreshed  at 
the  end  of  its  period,  at  which  time  execution  can  resume  at  the  server’s  assigned  priority.  A 
server  can  resume  its  execution  at  its  assigned  priority,  only  when  its  budget  is  refreshed. 

Figure  2-1  shows  the  average  response  times  of  the  different  scheduling  algorithms  as  a 
function  of  average  aperiodic  workload.  When  the  average  aperiodic  workload  is  small  com¬ 
pared  with  the  sporadic  server  size,  randomly  arriving  requests  are  likely  to  find  the  server 
available  and  can  successfully  preempt  the  periodic  tasks.  This  results  in  good  perfor¬ 
mance.  For  example,  when  the  average  aperiodic  workload  is  5%,"'°  the  deferrable  and 
sporadic  server  response  time  is  about  10%  of  the  average  background  response  time, 
while  the  average  polling  response  time  is  about  65%  of  background  response  time.  (This 
means  the  sporadic  server  gives  about  6  times  faster  response  than  polling  and  10  times 
faster  than  background  service.)  When  the  aperiodic  workload  increases,  the  likelihood  of 
server  availability  decreases  and  the  resulting  performance  advantage  also  decreases.  For 
example,  when  the  aperiodic  load  is  55%,  the  different  server  algorithms  do  not  give  signif¬ 
icant  performance  improvement  over  background  service. 


^is  means  each  server’s  period  must  not  be  greater  than  the  shortest  period  of  all  the  periodic  tasks.  The 
sporadic  server  and  polling  server  can  have  a  period  equal  to  that  of  the  shortest  period  task.  As  mentioned 
earlier  in  this  section,  however,  the  deferrable  server  must  have  an  even  shorter  period. 

5%  average  aperiodic  workload  means  that  in  the  long  run.  the  aperiodic  requests  consume  about  5%  of 
the  CPU  cycles,  although  the  number  of  requests  and  their  execution  time  vary  from  period  to  period  and  from 
request  to  request. 
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2.4.  Task  Synchronization 

In  the  previous  sections  we  have  discussed  the  scheduling  of  independent  tasks.  Tasks, 
however,  do  interact.  In  this  section,  we  will  discuss  how  the  rate  monotonic  scheduling  the¬ 
ory  can  be  applied  to  real-time  tasks  that  must  Interact.  The  discussion  is  limited  in  this 
paper  to  scheduling  within  a  uniprocessor.  Readers  who  are  interested  in  the  multiproces¬ 
sor  synchronization  problem  should  see  [Rajkumar  et  al.  88]. 

Common  synchronization  primitives  include  semaphores,  locks,  monitors,  and  Ada  rendez¬ 
vous.  Although  the  use  of  these  or  equivalent  methods  is  necessary  to  protect  the  consis¬ 
tency  of  shared  data  or  to  guarantee  the  proper  use  of  nonpreemptable  resources,  their  use 
may  jeopardize  the  ability  of  the  system  to  meet  its  timing  requirements.  In  fact,  a  direct 
application  of  these  synchronization  mechanisms  may  lead  to  an  Indefinite  period  of  priority 
inversion  and  low  schedulability. 

Example  6:  Suppose  J^,  J2,  and  1/3  are  three  jobs  arranged  in  descending  order  of 
priority  with  having  the  highest  priority.  We  assume  that  jobs  and  J3  share  a 
data  structure  guarded  by  a  binary  semaphore  S.  Suppose  that  at  time  job  J3 
locks  the  semaphore  S  and  executes  its  critical  section.  During  the  execution  of  the 
critical  section  of  job  1/3,  the  high  priority  job  is  initiated,  preempts  1/3  and  later 
attempts  to  use  the  shared  data.  However,  job  will  be  blocked  on  the  semaphore 
S.  We  would  hope  that  J^,  being  the  highest  priority  job,  is  blocked  no  longer  than 
the  time  for  job  1/3  to  complete  its  critical  section.  However,  the  duration  of  blocking 
is,  in  fact,  unpredictable.  This  is  because  job  1/3  can  be  preempted  by  the  interme¬ 
diate  priority  job  J2.  The  blocking  of  1/3,  and  hence  that  of  J-f,  will  continue  until  J2 
and  any  other  pending  intermediate  jobs  are  completed. 

The  blocking  period  in  this  example  can  be  arbitrarily  long.  This  situation  can  be  partially 
remedied  if  a  job  in  its  critical  section  is  not  allowed  to  be  preempted;  however,  this  solution 
is  only  appropriate  for  very  short  witical  sections  because  it  creates  unnecessary  blocking. 
For  instance,  once  a  low  priority  job  enters  a  long  critical  section,  a  high  priority  job  that 
does  not  access  the  shared  data  structure  may  be  needlessly  blocked. 

The  priority  ceiling  protocol  is  a  real-time  synchronization  protocol  with  two  important 
properties:  1)  freedom  from  mutual  deadlock,  and  2)  bounded  blocking,  which  means  that 
at  most  one  lower  priority  task  can  block  a  higher  priority  task  [Goodenough  &  Sha  88,  Sha 
et  al.  87].  There  are  two  ideas  in  the  design  of  this  protocol.  First  is  the  concept  of  priority 
inheritance:  when  a  task  x  blocks  the  execution  of  higher  priority  tasks,  task  x  executes  at 
the  highest  priority  level  of  all  the  tasks  blocked  by  x.  Secondly,  we  must  guarantee  that  a 
critical  section  is  allowed  to  start  execution  only  if  the  section  will  always  execute  at  a  priority 
level  that  is  higher  than  the  (inherited)  priority  levels  of  any  preempted  critical  sections.  It 
was  shown  in  [Sha  et  al.  87]  that  such  a  prioritized  total  ordering  in  the  execution  of  critical 
sections  ieads  to  the  two  desired  properties.  To  achieve  such  prioritized  totai  ordering,  we 
define  the  priority  ceiling  of  a  binary  semaphore  S  to  be  the  highest  priority  of  aii  tasks  that 
may  iock  S.  When  a  task  x  attempts  to  execute  one  of  its  criticai  sections,  it  wiii  be 
suspended  unless  its  priority  is  higher  than  the  priority  ceiiings  of  all  semaphores  currently 


14 


CMU/SEI-89-TR-14 


locked  by  tasks  other  than  t.  If  task  x  is  unable  to  enter  its  critical  section  for  this  reason, 
the  task  that  holds  the  lock  on  the  semaphore  with  the  highest  priority  ceiling  is  said  to  be 
blocking  x  and  hence  inherits  the  priority  of  x.  As  long  as  a  task  x  is  not  attempting  to  enter 
one  of  its  critical  sections,  it  will  preempt  every  task  that  has  a  lower  priority. 

Example  7:  Suppose  that  we  have  two  jobs  and  J2  in  the  system.  In  addition, 
there  are  two  shared  data  structures  protected  by  binary  semaphores  and  S2  re¬ 
spectively.  Suppose  the  sequence  of  processing  steps  for  each  job  is  as  follows. 


Recall  that  the  priority  of  job  is  assumed  to  be  higher  than  that  of  job  J2-  Thus,  the 
priority  ceilings  of  both  semaphores  S.,  and  are  equal  to  the  priority  of  job  J^. 
Suppose  that  at  time  Iq,  J2  is  initiate  and  it  begins  execution  and  then  locks 
semaphore  At  time  job  J■^  Is  initiated  and  preempts  job  J2  and  at  time  f2,  job 
tries  to  enter  its  critical  section  by  making  an  indivisible  system  call  to  execute 
P(S.,).  However,  the  runtime  system  will  find  that  the  priority  of  is  not  higher  than 
the  priority  ceiling  of  locked  semaphore  82-  Hence,  the  runtime  system  suspends 
job  without  locking  S^.  Job  J2  now  inherits  the  priority  of  job  and  resumes  ex¬ 
ecution.  Note  that  is  blocked  outside  its  critical  section.  As  is  not  given  the  lock 
on  S.|  but  suspended  instead,  the  potential  deadlock  involving  and  J2  is 
prevented.  Once  J2  exits  its  critical  section,  it  will  return  to  its  assigned  priority  and 
immediately  be  preempted  by  job  J^.  From  this  point  on,  will  execute  to  comple¬ 
tion,  and  then  J2  will  resume  its  execution  until  its  completion. 

Let  jB,-  be  the  longest  duration  of  blocking  that  can  be  experienced  by  task  Xj.  The  following 
two  theorems  indicate  whether  the  deadlines  of  a  set  of  periodic  tasks  can  be  met  if  the 
priority  ceiling  protocol  is  used. 

Theorem  3:  A  set  of  n  periodic  tasks  using  the  priority  ceiling  protocol  can  be 
scheduled  by  the  rate  monotonic  algorithm,  for  all  task  phasings,  if  the  following 
condition  is  satisfied  [Sha  et  al.  87]: 


Theorem  4:  A  set  of  n  periodic  tasks  using  the  priority  ceiling  protocol  can  be 
scheduled  by  the  rate  monotonic  algorithm  for  all  task  phasings  if  the  following 
condition  is  satisfied  [Sha  et  al.  87]. 


mn 


ik,r)eRi 


where  C,-,  T,-,  and  /?,•  are  defined  in  Theorem  2,  and  fi,-  is  the  worst-case  blocking 
time  for  Xj. 
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Remark:  Theorems  3  and  4  generalize  Theorems  1  and  2  by  taking  blocking  into  considera¬ 
tion.  The  Bj’s  in  Theorems  3  and  4  can  be  used  to  account  for  any  delay  caused  by 
resource  sharing.  Note  that  the  upper  limit  of  the  summation  in  the  theorem  is  (/-  1)  in¬ 
stead  of  i,  as  in  Theorem  2. 

In  the  application  of  Theorems  3  and  4,  it  is  important  to  realize  that  under  the  priority  ceiling 
protocol,  a  task  x  can  be  blocked  by  a  lower  priority  task  Xl  if  Xl  may  lock  a  semaphore  S 
whose  priority  ceiling  is  higher  than  or  equal  to  the  priority  of  task  x,  even  if  x  and  Xl  do  not 
share  any  semaphore.  For  example,  suppose  that  Xl  locks  S  first.  Next,  x  is  initiated  and 
preempts  Xl-  Later,  a  high  priority  task  x^  is  initiated  and  attempts  to  lock  S.  Task  x^  will  be 
blocked.  Task  Xl  now  inherits  the  priority  of  x^  and  executes.  Note  that  x  has  to  wait  for  the 
critical  section  of  Xl  even  though  x  and  Xl  do  not  share  any  semaphore.  We  call  such  block¬ 
ing  push-through  blocking.  Push-through  blocking  is  the  price  for  avoiding  unbounded  prior¬ 
ity  inversion.  If  task  Xl  does  not  Inherit  the  priority  of  x^,  task  x^  can  be  indirectly  preempted 
by  task  x  and  all  the  tasks  that  have  priority  higher  than  that  of  Xl.  Finally,  we  want  to  point 
out  that  even  if  task  x^  does  not  attempt  to  lock  S  but  attempts  to  lock  another  unlocked 
semaphore,  x^  will  still  be  blocked  by  the  priority  ceiling  protocol  because  the  priority  of  Xj^  is 
not  higher  than  the  priority  ceiling  of  S.  We  term  this  form  of  blocking  as  ceiling  blocking. 
Ceiling  block  is  the  price  for  ensuring  the  freedom  of  deadlock  and  the  property  of  a  task 
being  blocked  at  most  once. 


2.5.  An  Example  Application  of  the  Theory 

In  this  section,  we  give  a  simple  example  to  Illustrate  the  application  of  the  scheduling  the¬ 
ory. 

Example  8:  Consider  the  following  task  set. 

1.  Emergency  handling  task:  execution  time  =  5  msec;  worst  case  inter¬ 
arrival  time  =  50  msec;  deadline  is  6  msec  after  arrival. 

2.  Aperiodic  event  handling  tasks:  average  execution  time  =  2  msec; 
average  inter-arrival  time  =  40  msec;  fast  response  time  is  desirable 
but  there  are  no  hard  deadlines. 

3.  Periodic  task  x^:  execution  time  =  20  msec;  period  =  100  msec;  dead¬ 
line  is  at  the  end  of  each  period. 

In  addition,  X3  may  block  x^  for  10  msec  by  using  a  shared  communi¬ 
cation  server,  and  task  Xo  may  block  x.  for  20  msec  by  using  a  shared 
data  object. 

4.  Periodic  task  X2:  execution  time  =  40  msec;  period  =  150  msec;  dead¬ 
line  is  20  msec  before  the  end  of  each  period. 

5.  Periodic  task  X3:  execution  time  =  100  msec;  period  =  350  msec;  dead¬ 
line  is  at  the  end  of  each  period. 

Solution:  First,  we  create  a  sporadic  server  for  the  emergency  task,  with  a  period  of  50 
msec  and  a  service  time  5  msec.  Since  the  server  has  the  shortest  period,  the  rate 
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monotonic  algorithm  will  give  this  server  the  highest  priority.  It  follows  that  the  emergency 
task  can  meet  its  deadline. 

Since  the  aperiodic  tasks  have  no  deadlines,  they  can  be  assigned  a  low  background  prior¬ 
ity.  However,  since  fast  response  time  is  desirable,  we  create  a  sporadic  server  executing  at 
the  second  highest  priority.  The  size  of  the  server  is  a  design  issue.  A  larger  server  (i.e.,  a 
server  with  higher  utilization)  needs  more  processor  cycles  but  will  give  better  response 
time.  In  this  example,  we  choose  a  large  server  with  a  period  of  100  msec  and  a  service 
time  of  10  msec.  We  now  have  two  tasks  with  a  period  of  100  msec,  the  aperiodic  server 
and  periodic  task  The  rate  monotonic  algorithm  allows  us  to  break  the  tie  arbitrarily,  and 
we  let  the  server  have  the  higher  priority. 

We  now  have  to  check  if  the  three  periodic  tasks  can  meet  their  deadlines.  Since  under  the 
priority  ceiling  protocol  a  task  can  be  blocked  by  lower  priority  tasks  at  most  once,  the  max¬ 
imal  blocking  time  for  task  is  Bi  =  max(10,  20)  msec  =  20  msec.  Since  T3  may  lock  the 
semaphore  S^,  associated  with  the  communication  server  and  the  priority  ceiling  of  is 
higher  than  that  of  task  T2,  task  T2  can  be  blocked  by  task  X3  for  10  msec.^''  Finally,  task  13 
has  to  finish  20  msec  earlier  than  the  nominal  deadline  for  a  periodic  task.  This  is  equivalent 
to  saying  that  13  will  always  be  blocked  for  an  additional  20  msec  but  its  deadline  is  at  the 
end  of  the  period.  Hence,  ^2  =  (10  +  20)  msec  =  30  msec.^^  At  this  point,  we  can  directly 
apply  Theorem  4.  However,  we  can  also  reduce  the  number  of  steps  in  the  analysis  by 
noting  that  period  50  and  100  are  harmonics  and  we  can  treat  the  emergency  server  as  if  it 
has  a  period  of  100  msec  and  a  service  time  of  1 0  msec,  instead  of  a  period  of  50  msec  and 
a  service  time  of  5  msec.  We  now  have  three  tasks  with  a  period  of  100  msec  and  an  execu¬ 
tion  time  of  20  msec,  1 0  msec,  and  1 0  msec  respectively.  For  the  purpose  of  analysis,  these 
three  tasks  can  be  replaced  by  a  single  periodic  task  with  a  period  of  1 00  msec  and  an 
execution  time  of  40  msec  (20  +  10  +  10).  We  now  have  the  following  three  equivalent 
periodic  tasks  for  analysis: 

•  Task  Tv  Ci  =  40  :  T,  =  100  ;  6^  =  20  ;  ^  =  0.4 

•  Task  13:  =  40  ;  T2  =  150  ;  62  =  30  :  ^2  =  0.267 

•  Task  T^:  =  1 00  ]  7^  =  350  ]  =  0  j  L/3  =  0.286 

Using  Theorem  4: 

1.  Task  Tv  Check  ^  T,.  Since  40  20  <  100,  taskx^  is  schedulable. 

2.  Task  T2:  Check  whether  either 

C., C2  +  B2  ^  T^  40-»-40-»-30>  100 

or  2Ci  +  ^ B2  ^  T2  80 -»-40-»-30=  150 


’’This  may  occur  if  Xg  blocks  arxJ  inherits  the  priority  of  t,. 

’^Note  that  the  biocked-at-most-once  result  does  not  apply  here,  ft  only  applies  to  blocking  caused  by  task 
synchronization  using  the  priority  ceiling  protocol. 
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Task  T2  is  schedulable  and  in  the  worst-case  phasing  will  meet  its  deadline 
exactly  at  time  150. 


Task  X 

3:  Check  whether  either 

C2  +  C3  ^  T| 

40 -1-40 -1-1 00  > 

100 

or 

2C, 

VI 

-1- 

+ 

80 -1-40 -1-1 00  > 

150 

or 

2Ci 

+  2  C2  +  ^  2  Tj 

80 -1-80 -1-1 00  > 

200 

or 

3Ci 

+  2  C2  +  ^  2,  T2 

120-1-80-1-100  = 

=  300 

or 

4Ci 

+  3C2  Cg  ^  7^ 

160-1-120-1-100 

>350 

Task  T3  is  also  schedulable  and  in  the  worst-case  phasing  will  meet  its  deadline  exactly  at 
time  300.  It  follows  that  all  three  periodic  tasks  can  meet  their  deadlines. 

We  now  determine  the  response  time  of  the  aperiodics.  The  server  capacity  is  1 0%  and  the 
average  aperiodic  workload  is  5%  (2/40).  Because  most  of  the  aperiodic  arrivals  can  find 
"tickets,"  we  would  expect  a  good  response  time.  Indeed,  using  a  M/M/1  [Kleinrock  75]  ap¬ 
proximation  for  the  lightly  loaded  server,  the  expected  response  time  for  the  aperiodics  is 
W  =  E[S]/(1  -  p)  =  2/(1  -  (0.05/0.10))  =  4  msec  where  E[S]  is  the  average  execution  time  of 
aperiodic  tasks  and  p  is  the  average  server  utilization.  Finally,  we  want  to  point  out  that 
although  the  worst-case  total  periodic  and  server  workload  is  95%,  we  can  still  do  quite  a  bit 
of  background  processing  since  the  soft  deadline  aperiodics  and  the  emergency  task  are 
unlikely  to  fully  utilize  the  servers.  The  results  derived  for  this  example  show  how  the 
scheduling  theory  puts  real-time  programming  on  an  analytic  engineering  basis. 
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3.  Real-Time  Scheduling  in  Ada 

Although  Ada  was  intended  for  use  in  building  real-time  systems,  its  suitability  for  real-time 
programming  has  been  widely  questioned.  Many  of  these  questions  concern  practical  is¬ 
sues,  such  as  the  cost  of  performing  a  rendezvous,  minimizing  the  duration  of  interrupt 
masking  in  the  runtime  system,  providing  efficient  support  for  interrupt  handling,  etc.  These 
problems  are  being  addressed  by  compiler  vendors  who  are  aiming  at  the  real-time  market. 
More  important  are  concerns  about  the  suitability  of  Ada’s  conceptual  model  for  dealing  with 
real-time  programming.  For  example,  tasks  in  Ada  run  nondeterministically,  making  it  hard 
for  traditional  real-time  programmers  to  decide  whether  any  tasks  will  meet  their  deadlines. 
In  addition,  the  scheduling  rules  of  Ada  don't  seem  to  support  prioritized  scheduling  well. 
Prioritized  tasks  are  queued  In  FIFO  order  rather  than  by  priority;  high  priority  tasks  can  be 
delayed  indefinitely  when  calling  low  priority  tasks  (due  to  priority  inversion;  see 
[Goodenough  &  Sha  88]  for  an  example);  and  task  priorities  cannot  be  changed  when  appli¬ 
cation  demands  change  at  runtime.  Fortunately,  it  appears  that  none  of  these  problems 
presents  insurmountable  difficulties;  solutions  exist  within  the  current  language  framework, 
although  some  language  changes  would  be  helpful  to  ensure  uniform  implementation  sup¬ 
port.  The  Real-Time  Scheduling  in  Ada  Project  at  the  SEI  is  specifying  coding  guidelines 
and  runtime  system  support  needed  to  use  analytic  scheduling  theory  in  Ada  programs. 
The  guidelines  are  still  evolving  and  being  evaluated;  but  so  far,  it  seems  likely  they  will 
meet  the  needs  of  a  useful  range  of  systems. 

The  rest  of  this  section  summarizes  the  approach  being  taken  by  the  project,  and  then 
shows  how  Ada’s  scheduling  rules  can  be  interpreted  to  support  the  requirements  of  rate 
monotonic  scheduling  algorithms. 


3.1.  Ada  Real-Time  Design  Guidelines 

The  coding  and  design  guidelines  being  developed  by  the  SEI  Real-Time  Scheduling  in  Ada 
Project  reflect  a  basic  principle  of  real-time  programming  —  write  systems  in  a  way  that 
minimizes  priority  inversion;  that  is  minimize  the  time  a  high  priority  task  has  to  wait  for  the 
execution  of  lower  priority  tasks. 

For  example,  consider  a  set  of  periodic  tasks,  called  clients,  that  must  exchange  data 
among  themselves.  They  do  not  call  each  other  to  exchange  data.  Instead,  whenever  they 
must  read  or  write  shared  data  or  send  a  message,  they  call  a  server  task.  Each  server  task 
has  a  simple  structure  —  an  endless  loop  with  a  single  select  statement  with  no  guards.^^ 
This  structure  models  the  notion  of  critical  regions  guarded  by  a  semaphore;  each  entry  is  a 
critical  region  for  the  task  calling  the  entry. 


prohibition  against  guards  simplifies  the  scheduiabiiity  analysis  and  the  runtime  system  impiementation, 
but  otherwise  is  not  essential. 
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Client  tasks  are  assigned  priorities  acxjording  to  rate  monotonic  principles;  that  is,  tasks  with 
the  shortest  periods  are  given  the  highest  priorities.  There  are  two  options  when  assigning 
a  priority  to  a  server.  If  the  Ada  runtime  system  supports  the  priority  ceiling  protocol  directly 
(the  next  section  explains  why  the  runtime  system  is  allowed  to  support  the  protocol),  then 
give  the  server  a  low  or  an  undefined  priority.  In  addition,  tell  the  runtime  system  the  priority 
ceiling  of  the  server,  i.e.,  the  highest  priority  of  all  its  clients.  Then,  when  a  server  is  execut¬ 
ing  on  behalf  of  a  client  task,  no  other  client  task  will  be  allowed  to  call  any  server  unless  the 
client’s  priority  Is  higher  than  the  executing  server’s  priority  ceiling.  If  the  client  does  not 
have  a  sufficiently  high  priority,  its  call  will  be  blocked  (i.e.,  the  caller  will  be  preempted  just 
before  the  call  would  be  placed  on  an  entry’s  queue),  and  the  server’s  priority  will  be  raised 
to  the  priority  of  the  blocked  caller.  This  treatment  of  competing  calls  will  ensure  that  a  high 
priority  task  is  blocked  at  most  once  by  a  server  [Goodenough  &  Sha  88].  Moreover,  be¬ 
cause  calls  are  preempted  before  they  are  queued,  when  the  executing  server  completes  its 
rendezvous,  the  highest  priority  blocked  task  will  be  able  to  execute.  In  effect  calls  will  be 
processed  in  priority  order,  and  mutual  deadlock  caused  by  nested  server  calls  will  be  Im¬ 
possible. 

If  the  priority  ceiling  protocol  is  not  directly  supported  by  an  Ada  runtime  system,  the  effect 
of  the  protocol  can  often  nonetheless  be  achieved.  Suppose  a  server  is  used  to  synchro¬ 
nize  access  to  data  shared  by  several  tasks.  The  ceiling  protocol  requires  that  while  a  ser¬ 
ver  is  in  rendezvous  with  a  client  no  other  server  be  called  by  any  client  unless  the  client 
has  a  priority  higher  than  the  server’s  priority  ceiling.  This  effect  can  be  easily  achieved 
using  existing  Ada  runtime  systems  by  assigning  the  server  task  a  ceiling  priority,  i.e.,  a 
priority  that  is  one  greater  than  the  priority  of  its  highest  priority  caller.  In  this  case,  the 
server  will  be  either  waiting  for  a  client  or  be  serving  a  client  at  a  priority  that  prevents  other 
clients  from  executing  and  calling  any  server  with  an  equal  or  lower  priority  ceiling.  This 
approach  avoids  the  prioritized  queueing  problem  because  there  will  never  be  more  than 
one  queued  client  task.  It  is  also  not  hard  to  see  why  mutual  deadlock  will  be  impossible. 

This  simple  approximation  to  the  ceiling  protocol  will  not  work,  however,  if  the  server  task 
suspends  itself  while  in  rendezvous.  Such  a  suspension  will  allow  client  tasks  with  priorities 
lower  than  that  of  the  suspended  server  to  rendezvous  with  other  servers;  this  violates  the 
principle  of  the  ceiling  protocol.  Such  a  suspension  can  be  caused  by  either  the  server’s 
need  to  synchronize  with  external  I/O  events  in  a  uniprocessor  or  the  server’s  need  to  ren¬ 
dezvous  with  another  task  in  another  processor  in  a  multiprocessor.  When  a  server  task 
can  suspend  itself  while  in  a  rendezvous,  care  must  be  taken  to  ensure  that  no  calls  are 
accepted  by  other  servers  having  the  same  or  a  lower  ceiling  priority.  In  addition,  because 
queues  can  now  develop,  it  Is  Important  that  queued  calls  be  serviced  In  priority  order. 
Preventing  inappropriate  server  calls  and  ensuring  priority  queueing  can  require  quite  com¬ 
plex  code  involving  entry  families,  so  this  method  of  implementing  the  ceiling  protocol  is 
probably  unsuitable  when  server  tasks  are  allowed  to  suspend  themselves. 

From  a  schedu lability  viewpoint,  the  execution  time  spent  in  each  rendezvous  with  a  server 
that  does  not  suspend  itself  is  counted  as  part  of  the  computing  time,  Cj,  for  the  client  task 
Tj.  Because  the  use  of  servers  is  a  synchronization  problem,  Theorems  3  and  4  must  be 
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used  to  account  for  blocking  time.  Under  the  priority  ceiling  protocol,  the  maximum  blocking 
time  for  a  nonserver  task  at  priority  level  i  is  the  longest  entry  call  by  a  lower  level  client  task 
to  a  server  whose  priority  ceiling  is  equal  to  or  higher  than  the  priority  of  /.  (Note  that  this 
definition  of  blocking  time  means  that  even  if  a  task,  x,  makes  no  server  calls,  the 
schedulability  analysis  for  x  must  include  blocking  time  for  lower  priority  client  tasks;  see 
Example  above.)  If  a  server  can  suspend  Itself,  it  is  sufficient  to  treat  the  suspension  time 
as  server  execution  time  in  the  schedulability  analysis;  work  is  underway  to  see  when  less 
pessimistic  treatment  may  be  possible. 

The  worst-case  blocking  time  for  a  client  task  is  the  same  whether  the  ceiling  protocol  is 
supported  directly  by  the  runtime  system  or  is  approximated  by  giving  the  server  an  appro- 
FMiately  high  priority.  The  essential  difference  between  the  direct  implementation  and  the  ap¬ 
proximation  method  is  that  the  server  priority  will  be  raised  only  when  necessary  when  the 
direct  implementation  Is  used.  This  tends  to  generate  less  blocking  on  average  and  hence 
better  response  time  when  aperiodic  tasks  have  a  priority  below  that  of  a  server’s  ceiling.  In 
addition,  in  transient  overload  situations,  noncritical  periodic  tasks  having  a  priority  lower 
than  a  server’s  ceiling  are  less  likely  to  miss  their  deadlines.  In  short,  the  direct  implemen¬ 
tation  gives  better  average  case  behavior,  especially  when  the  entry  calls  are  relatively  long. 
When  the  entry  calls  are  short  compared  with  client  task  execution  times,  the  performance 
difference  is  insignificant. 

Despite  the  complications  that  arise  when  server  tasks  can  suspend  themselves,  our  point  is 
that  the  schedulability  theory  can  be  readily  applied  to  Ada  programs,  ensuring  that  dead¬ 
lines  are  met  even  when  timelines  are  nondeterministic.  In  the  next  section  we  discuss  how 
to  interpret  Ada’s  scheduling  rules  so  that  Ada  runtime  systems  can  support  rate  monotonic 
scheduling  algorithms  directly. 


3.2.  On  Ada  Scheduling  Rules 

First  of  all,  the  Ada  tasking  model  is  well-suited,  in  principle,  to  the  use  of  the  analytic 
scheduling  theories  presented  in  this  paper.  When  using  these  theories,  a  programmer 
doesn’t  need  to  know  when  tasks  are  running  to  be  sure  that  deadlines  will  be  met.  That  is, 
both  Ada  and  the  theory  abstract  away  the  details  of  an  execution  timeline.  Although  Ada 
tasks  fit  well  with  the  theory  at  the  conceptual  level,  Ada  and  the  theory  differ  on  the  rules  for 
determining  when  a  task  is  eligible  to  run  and  Its  execution  priority.  For  example,  if  a  high 
priority  task  calls  a  server  task  that  is  already  in  rendezvous  with  a  low  priority  task,  the 
rendezvous  can  continue  at  the  priority  of  the  task  being  served  instead  of  being  increased 
because  a  high  priority  task  is  waiting.  Under  these  circumstances,  the  high  priority  task 
can  be  blocked  as  long  as  there  are  medium  priority  jobs  able  to  run.  But  there  are  a  variety 
of  solutions  to  this  problem.  The  most  general  solution  within  the  constraints  of  the  lan¬ 
guage  is  simply  to  not  use  pragma  PRIORITY  at  all.  If  all  tasks  in  a  program  have  no  as¬ 
signed  priority,  then  the  runtime  system  is  free  to  use  any  convenient  algorithm  for  deciding 
which  eligible  task  to  run.  An  implementation-dependent  pragma  could  be  used  to  give 
"scheduling  priorities"  to  tasks,  i.e.,  indications  of  scheduling  importance  that  would  be  used 


CMU/SEI-89-TR-14 


21 


in  accordance  with  rate  monotonic  scheduling  algorithms.  This  approach  would  even  allow 
"priorities"  to  be  changed  dynamically  by  the  programmer  because  such  changes  only  affect 
the  scheduling  of  tasks  that,  in  a  legalistic  sense,  have  no  Ada  priorities  at  all.  The  only 
problem  with  this  approach  is  that  entry  calls  are  still  queued  in  FIFO  order  rather  than  by 
priority.  However,  this  problem  can  often  be  solved  by  using  a  coding  style  that  prevents 
queues  from  having  more  than  one  task,  making  the  FIFO  issue  irrelevant,  or  by  suspending 
calling  tasks  just  before  they  are  queued.  Of  course,  telling  programmers  to  assign 
"scheduling  priorities"  to  tasks  but  not  to  use  pragma  PRIORITY,  surely  says  we  are  fighting 
the  language  rather  than  taking  advantage  of  it  But  the  Important  point  is  that  no  official 
revisions  to  the  language  are  needed  to  take  advantage  of  the  scheduling  theories  and  algo- 
n'thms  described  in  this  paper  and  being  developed  by  our  project.  Here  are  the  relevant 
Ada  rules  and  appropriate  ways  of  interpreting  them: 

•  CPU  allocation:  priorities  must  be  observed.  Ada  requires  that  the  highest  prior¬ 
ity  task  eligible  to  run  be  given  the  CPU  when  this  is  "sensible."  "Sensible"  for  a 
uniprocessor  is  usually  interpreted  to  mean  that  if  an  entry  call  by  an  executing 
task  can  be  accepted,  the  call  must  be  accepted  and  no  lower  priority  task  can 
be  allowed  to  execute.  Although  this  interpretation  may  seem  to  be  obviously 
the  best,  it  is  In  fact  not  correct  for  the  priority  celling  protocol,  which  gives  bet¬ 
ter  service  to  high  priority  tasks  and  avoids  deadlock  by  blocking  calls  from 
medium  priority  tasks  when  certain  low  priority  entry  calls  are  already  in 
progress.  For  example  (see  Figure  3-1),  suppose  a  resource  is  guarded  by  a 
server  task  S,  and  suppose  a  low  priority  tesk  is  in  rendezvous  with  S.  Also 
suppose  the  priority  ceiling  of  S  is  H  (i.e.,  the  highest  priority  task  that  can  call  S 
has  priority  H).  Now  suppose  execution  of  the  rendezvous  is  preempted  by  a 
medium  priority  task  M,  whose  priority  is  less  than  H.  Suppose  M  tries  to  call  T, 
a  server  other  than  S.  The  priority  ceiling  protocol  says  that  the  call  from  M 
must  be  blocked,  but  the  normal  interpretation  of  Ada’s  scheduling  rules  would 
imply  that  the  call  of  M  must  be  accepted  because  M  is  the  highest  priority  task 
that  is  eligible  to  run  and  T  is  able  to  accept  the  call. 

Solution:  There  are  several  solutions  to  this  problem.  First  of  all,  the  priority 
ceiling  protocol  need  not  be  applied  to  all  called  Ada  tasks;  it  need  only  be  ap¬ 
plied  to  those  tasks  that  are  servers  in  the  sense  defined  in  the  previous  sec¬ 
tion.  The  simplest  approach  (in  terms  of  living  within  the  current  interpretations 
of  Ada  rules)  is  to  give  each  server  task  a  unique  priority  that  is  higher  than  the 
priority  of  any  task  calling  the  server. 

Another  approach  is  to  implement  the  priority  ceiling  protocol  directly  for  server 
tasks.  This  approach  is  clearly  allowed  by  Ada’s  scheduling  rules  as  long  as 
the  server  task  is  given  no  assigned  priority.  A  server  task  with  no  assigned 
priority  can  preempt  any  other  task  at  any  time,  because  Ada’s  scheduling 
rules.  In  essence,  do  not  specify  how  tasks  with  no  priority  are  scheduled.  For 
example,  task  S  is  allowed  to  preempt  task  M  just  at  the  point  where  M  is  about 
to  call  T.  Moreover,  when  a  server  with  no  assigned  priority  is  in  a  rendezvous 
with  a  client  tasK  the  Ada  rules  say  the  server  is  executed  with  "at  least"  the 
priority  of  the  client  task.  Because  the  priority  ceiling  rules  require  that  the  ser¬ 
ver  task  be  executed  with  the  priority  of  the  calling  task  or  of  any  blocked  task 
(whichever  is  higher),  the  Ada  rule  allows  the  server  to  be  executed  with  the 
(higher)  priority  of  the  blocked  task.  In  the  example,  this  means  S,  in  effect, 
continues  its  rendezvous  with  M’s  priority.  When  the  rendezvous  is  complete. 
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M’s  call  is  allowed  to  succeed.  Hence,  the  priority  ceiling  protocol  can  certainly 
be  implemented  directly  when  server  tasks  have  no  assigned  priority. 


H 

M 

L 

S 

T 


©  (D  ©  ® 

Q  L  calls  S;  S  executes  on  behalf  of  L. 

M  precmpis  S  and  hence,  L. 

@  M  tries  to  call  T,  but  is  blocked; 

S  resumes  execution. 


©  © 

Q  M's  ciU  succeeds;  L  ij  precmp(cd 
@  M  finishes. 

©  L  finishes. 


Figure  3-1 :  Blocking  Due  to  the  Priority  Ceiling  Protocol 

A  more  aggressive  interpretation  of  Ada  rules  is  to  note  that  a  high  priority  task 
must  preempt  a  lower  priority  task  only  when  it  is  "sensible"  to  do  so.  Surely  it 
is  not  "sensible"  for  a  medium  priority  task  to  start  its  rendezvous  with  T  if  the 
effect  could  be  to  delay  the  execution  of  a  high  priority  task  unnecessarily. In 
short,  the  priority  ceiling  protocol  provides  a  set  of  rules  saying  when  it  is 
"sensible"  to  allow  a  higher  priority  task  to  run,  and  hence,  these  rules  can  be 
followed  directly  by  the  runtime  system  even  when  a  server  task  has  an  as¬ 
signed  priority. 

In  short,  there  are  several  ways  to  argue  that  it  is  possible  to  support  the  priority 
ceiling  protocol’s  view  of  priorities  within  the  current  Ada  rules. 

•  Hardware  task  priority:  always  higher  than  software  task  priorities.  This  Ada 
rule  reflects  current  hardware  designs,  but  hardware  interrupts  should  not  al¬ 
ways  have  the  highest  priority  from  the  viewpoint  of  the  rate  monotonic  theory. 

Solution:  When  handling  an  interrupt  that,  in  terms  of  the  rate  monotonic  theory, 
should  have  a  lower  priority  than  the  priority  of  some  application  task,  keep  the 
interrupt  handling  actions  short  (which  is  already  a  common  practice)  and  in¬ 
clude  the  interrupt  handling  duration  as  blocking  time  in  the  rate  monotonic 
analysis.  In  other  words,  use  the  scheduling  theory  to  take  into  account  the 
effect  of  this  source  of  priority  inversion. 


^^Suppose  S  can  call  T  (such  a  call  models  a  nested  critical  region).  If  M's  rendezvous  with  T  is  allowed  to 
start  and  H  then  calls  S,  H  could  be  delayed  until  the  completion  of  both  S  and  Ts  rendezvous;  that  is,  H  would 
be  blocked  by  more  than  one  lower  priority  task.  This  is  one  of  the  reasons  for  preventing  M's  call. 
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•  Priority  rules  for  task  rendezvous: 

•  Selective  wait:  priority  can  be  ignored.  That  is,  the  scheduler  is  allowed, 
but  not  required,  to  take  priorities  into  account  when  tasks  of  different  pri¬ 
orities  are  waiting  at  open  select  alternatives. 

Solution:  Because  Ada  allows,  but  does  not  require  taking  these  priorities 
into  account,  ensure  that  the  runtime  system  does  use  these  priorities  to 
decide  which  call  to  accept.  Alternatively,  if  the  priority  ceiling  protocol  is 
used,  there  is  never  more  than  one  waiting  task  to  select. 

•  Called  task  priority:  only  increased  during  rendezvous. 

Solution:  Use  the  solutions  discussed  under  "CPU  allocation"  above;  that 
Is,  increase  the  priority  of  a  server  when  the  ceiling  protocol  says  this  is 
"sensible,"  or  give  the  called  task  no  priority  at  all  and  use  priority  ceiling 
rules  to  say  when  the  server  is  allowed  to  execute,  or  give  servers  a  pri¬ 
ority  higher  than  that  of  their  callers. 

•  FIFO  entry  queues:  Ada  requires  that  the  priority  of  calling  tasks  be  ignored; 
calls  must  be  serviced  in  their  order  of  arrival,  not  in  order  of  priority.  Using 
FIFO  queues  rather  than  prioritized  queues  usually  has  a  serious  negative  ef¬ 
fect  on  real-time  schedulability.  FIFO  queues  must  be  avoided. 

Solution:  As  noted  earlier,  often  it  is  possible  to  avoid  FIFO  queueing  by 
preventing  queues  from  being  formed  at  all.  If  the  runtime  system  does  not 
prevent  queues  from  forming,  then  entry  families  can,  of  course,  be  used  to  get 
the  effect  of  prioritized  queueing. 

•  Task  priorities:  fixed.  This  rule  is  inappropriate  when  task  priorities  need  to  be 
changed  at  runtime.  For  example,  when  a  new  mode  is  initiated,  the  frequency 
of  a  task  and/or  its  criticality  may  change,  implying  its  priority  must  change.  In 
addition,  the  scheduling  rules  for  a  certain  class  of  aperiodic  servers  demand 
that  the  priority  of  such  a  server  be  lowered  when  it  is  about  to  exceed  the  max¬ 
imum  execution  time  allowed  for  a  certain  interval  of  time,  and  be  raised  when 
its  service  capacity  has  been  restored  [Sprunt  et  al.  89]. 

Solution:  When  an  application  needs  to  adjust  the  priority  of  a  task  at  runtime, 
this  task  should  be  declared  as  having  no  Ada  priority.  The  runtime  system  can 
then  be  given  a  way  of  scheduling  the  task  appropriately  by,  in  effect,  changing 
its  priority. 

From  what  our  project  has  learned  so  far,  it  seems  to  be  possible  in  practice  to  support 
analytic  scheduling  algorithms  in  Ada  by  using  an  enlightened  interpretation  of  Ada’s 
scheduling  rules  together  with  a  combination  of  runtime  system  modifications  and  appro¬ 
priate  coding  guidelines.  Of  course,  it  would  be  better  if  the  language  did  not  get  in  the  way 
of  priority  scheduling  principles.  The  future  revision  of  Ada  should  probably  reword  some  of 
these  rules  so  that  priority-based  scheduling  is  more  clearly  and  uniformly  supported. 
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4.  Conclusion 


Ada  tasking  was  intended  to  be  used  for  real-time  programming.  However,  the  Ada  tasking 
model  represents  a  fundamental  departure  from  the  traditional  cyclical  executive  model. 
Indeed,  the  dynamic  preemption  of  tasks  at  runtime  generates  nondeterministic  timelines 
that  are  at  odds  with  the  very  idea  of  a  fixed  execution  timeline  required  by  a  cyclical  execu¬ 
tive. 

In  this  paper,  we  have  reviewed  some  important  results  of  priority  scheduling  theory.  To¬ 
gether  with  Ada  tasking,  they  allow  programmers  to  reason  with  confidence  about  timing 
correctness  at  the  tasking  level  of  abstraction.  As  long  as  analytic  scheduling  algorithms  are 
supported  by  the  runtime  system  and  resource  utilization  bounds  on  CPU,  I/O  drivers,  and 
communication  media  are  observed,  the  timing  constraints  will  be  guaranteed.  Even  if  there 
is  a  transient  overload,  the  tasks  missing  deadlines  will  be  in  a  predefined  order. 

Although  the  treatment  of  priorities  by  the  current  Ada  tasking  model  can  and  should  be 
improved,  it  seems  that  the  scheduling  algorithms  can  be  used  today  within  the  existing  Ada 
rules  if  an  appropriate  coding  and  design  approach  is  taken,  and  if  schedulers  are  written  to 
take  full  advantage  of  certain  coding  styles  and  the  existing  flexibility  in  the  scheduling  rules. 
Additional  reports  on  how  this  can  be  done  are  in  preparation  at  the  Software  Engineering 
Institute. 
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